The startup configuration settings read by the RHQ Server are stored in the rhq-server.properties file located in the /bin directory of the server distribution. This file includes settings not persistent in the database (i.e. these startup settings are specific for a single RHQ Server instance - they are not applied across all RHQ Servers in the cloud). If you modify any setting in this file, you typically must restart the RHQ Server in order for the changes to take effect.
This rhq-server.properties file defines typical server settings such as the TCP ports that RHQ Server components listen to and the security settings for the server-agent communications subsystem.
The installer sets the initial values of these variables during installation. The values are customized by you during the installation process as per your requirements.
Below are these startup properties.
The rhq-server.properties file contains the database username and password. This password is not encrypted in earlier RHQ versions. Ensure this file is protected from unwanted access.
These properties defines the RHQ Server's database and how it can connect to it.
rhq.server.database.type-mapping |
Defines the vendor of your database that will be used as RHQ's backend persistence store. The only supported values are PostgreSQL or Oracle.
rhq.server.database.connection-url |
The JDBC URL that the RHQ Server will use when connecting to the database. An example is jdbc:postgresql://localhost:5432/rhq or jdbc:oracle:oci:@localhost:1521:orcl.
rhq.server.database.driver-class |
The fully qualified class name of the JDBC driver that the RHQ Server will use to communicate with the database. An example is org.postgresql.Driver or oracle.jdbc.driver.OracleDriver.
rhq.server.database.xa-datasource-class |
The fully qualified class name of the JDBC driver's XA DataSource that the RHQ Server will use to communicate with the database. An example is org.postgresql.xa.PGXADataSource or oracle.jdbc.xa.client.OracleXADataSource.
rhq.server.database.user-name |
The name of the user that the RHQ Server will use when logging into the database.
rhq.server.database.password |
The password of the database user that is used by the RHQ Server when logging into the database.
rhq.server.database.server-name |
The server name where the database is found. This must match the server in the connection URL. Currently only used when connecting to PostgreSQL.
rhq.server.database.port |
The port on which the database is listening. This must match the port in the connection URL. Currently only used when connecting to PostgreSQL.
rhq.server.database.db-name |
The name of the database. This must match the name found in the connection URL. Currently only used when connecting to PostgreSQL.
hibernate.dialect |
The name of the Hibernate dialect that identifies the strategy used by Hibernate to connect to and access your database. For example, the Postgres dialect is org.hibernate.dialect.PostgresSQLDialect.
rhq.server.quartz.driverDelegateClass |
Quartz is the scheduling engine used by RHQ. This is a Quartz configuration setting that is specific to your database and provides the strategy for how Quartz connects to and accesses your database.
rhq.server.quartz.selectWithLockSQL |
Quartz is the scheduling engine used by RHQ. This is a Quartz configuration setting that is specific to your database and provides the SQL that Quartz uses to obtain data from a specific table it needs to do its job.
rhq.server.quartz.lockHandlerClass |
Quartz is the scheduling engine used by RHQ. This is a Quartz configuration setting that is specific to your database.
These are settings that bind the RHQ Server to particular IP addresses and ports. You will normally only need to change these if you have firewall issues that require specific addresses and ports to be used.
jboss.bind.address |
The RHQ GUI Console (among other services) will bind to this IP address. This is the host in the RHQ Console URLs; e.g. the myhost in http://myhost:7080.
(
Prior to 2.1) If you change this value, and your Incoming Agent Communications Transport is set to servlet, you must change the value of the Incoming Agent Communications Bind Address setting to match this address.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
If you set this value to something other than 0.0.0.0, you must also set java.rmi.server.hostname to the same value as this jboss.bind.address property.
rhq.server.startup.web.http.port |
The RHQ GUI Console will listen to this port for unsecured HTTP requests coming in. This is the port number in the RHQ Console URLs; e.g. the 7080 in http://localhost:7080.
(
Prior to 2.1) If you change this value, and your Incoming Agent Communications Transport is set to servlet, you must change the value of the Incoming Agent Communications Port setting to match this port number.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.web.https.port |
The RHQ GUI Console will listen to this port for secured HTTPS requests coming in. This is the port number in the RHQ Console URLs; e.g. the 7443 in http://localhost:7443.
(
Prior to 2.1) If you change this value, and your Incoming Agent Communications Transport is set to sslservlet, you must change the value of the Incoming Agent Communications Port setting to match this port number.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.webservice.port |
Port used by an internal service.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.namingservice.port |
Port used by an internal service.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.namingservice.rmiport |
Port used by an internal service.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.jrmpinvoker.rmiport |
Port used by an internal service.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.pooledinvoker.rmiport |
Port used by an internal service.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.ajp.port |
Port used by an internal service.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.unifiedinvoker.port |
Port used by an internal service.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.startup.aspectdeployer.bind-port |
Port used by an internal service.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
(
Since 2.1)
These are settings that configure the RHQ Server to identify itself to, and communicate with, other RHQ Servers or server-side components. They are required for a single-server installation and also facilitate membership in a multi-server, High Availability, RHQ Server Cloud. Note that these settings can not be changed in the rhq-server.properties files but rather are managed via the RHQ GUI post-installation.
rhq.server.high-availability.name |
Each RHQ Server is identified by a unique name. The installer will default this value to the localhost name although it does not need to be a resolvable machine name. The only restriction is that all server names be unique in the RHQ server cloud.
Although present in rhq-server.properties this setting is managed only via the RHQ HA Administration Console.
rhq.server.maintenance-mode-at-start |
If true, the server will start in maintenance mode at startup. If false, whatever mode the server was in when it shutdown will be the mode it will be in when it starts up.
The public server endpoint IP address. This is the address that must be recognized by all agents needing access to this server. The installer will default this value to the localhost address.
This setting is managed only via the RHQ HA Administration Console.
The server endpoint address is used in conjunction with either HTTP Port or Secure HTTPS Port to provide High Availability server endpoints to agents.
RHQ performs load balancing and agent fail-over when operating with a multi-server configuration (RHQ Server Cloud). In certain situations, for example, regional datacenters, it may make sense for particular RHQ Agents to prefer (have affinity for), certain servers. RHQ Agents assigned to a particular Affinity Group will prefer RHQ Servers assigned to the same Affinity Group. Note that the pairing is not strict and RHQ can service any agent with any server depending on resource load and availability. By default a server is not assigned an Affinity Group. For larger Server Clouds Affinity Group management is performed via the RHQ GUI.
When installing or upgrading the RHQ server against an existing database the installer will present a list of previously installed RHQ Server Names. These Server Names represent the servers in the current RHQ Server Cloud. If you are performing an upgrade, or for some reason are re-installing an RHQ Server select the appropriate server name from the list. The installer will populate the other High Availability settings as previously configured for the server. The server name should not be changed (otherwise the installer will treat this as a new server installation) but the other HA settings can be updated at this time.
If you manually enter a new server name it will be installed as a new server. If no others exist this will be a single-server configuration. Otherwise, the new server will be added to the existing High Availability Server Cloud.
This list will not be presented if the database is new or there are no previously installed servers.
(
Prior to 2.1)
These are settings that configure the RHQ Server to participate in a RHQ Server cluster setup. You will normally only need to change these if you have firewall issues that require specific addresses and ports to be used. For low-level details about these JBossAS cluster settings, see http://wiki.jboss.org/wiki/Wiki.jsp?page=TwoClustersSameNetwork. All of these Cluster Binding settings are no longer used in RHQ version 2.1 and up.
If you change any of these cluster binding values, you must shutdown and restart the RHQ Server in order for the changes to take effect.
jboss.partition.name |
The name of the RHQ Server cluster partition. All RHQ Servers participating in the cluster must use the same name.
jgroups.bind_addr |
The bind address used by JGroups to support clustering communications.
If you have a multi-homed machine, set this to the appropriate NIC IP address.
If you do not plan on running the RHQ Server as part of a cluster of RHQ Servers,
you may set this to 127.0.0.1 so it binds only to the local loopback interface.
jgroups.udp.mcast_addr |
The multicast address used by the JGroups channel to broadcast messages to members of the cluster.
jboss.hapartition.mcast_port |
Used by an internal clustering service.
jboss.ejb3entitypartition.mcast_port |
Used by an internal clustering service to support EJB3 entity caching.
jboss.alertcachepartition.mcast_port |
Used by an internal clustering service to support alert caching.
rhq.server.startup.partition.udpLoopback |
On UNIX, this can typically be left as false. On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense), set this UDP loopback setting to true.
rhq.server.startup.hajndi.port |
Used by an internal service to define the port on which the HA-JNDI stub is made available.
rhq.server.startup.hajndi.rmiport |
Used by an internal service - to be used by the HA-JNDI service once bound.
rhq.server.startup.hajndi.autodiscoverygroupport |
Multicast port used for cluster auto-discovery.
rhq.server.startup.hajrmpinvoker.rmiport |
Used by an internal service.
rhq.server.startup.hapooledinvoker.port |
Used by an internal service.
jgroups.udp.ip_ttl |
Used by JGroups as a performance tuning parameter. See the JBossAS and JGroups documentation on the UDP protocol's "ip_ttl" setting for more information.
The Tomcat server is used to both accept user browser requests (to access the RHQ Server GUI) and to accept incoming agent messages that are coming in via the sslservlet transport mechanism.
rhq.server.tomcat.security.keystore.file |
The RHQ Console can accept browser requests or agent messages over HTTPS through the Tomcat server running inside the RHQ Server. If you want to authenticate your RHQ Console to remote browsers or authenticate agents whose messages are coming over the sslservlet transport, you need to put an SSL certificate in a keystore file. This setting points to the location of your keystore file - note that this filename must be a relative file path relative to the <RHQ Server Install Dir>/jbossas/server/default directory. The RHQ Server ships with a self-signed certificate in a default keystore file.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.keystore.password |
The password of the keystore file so it can be accessed in order to be able to serve the certificate to clients.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.keystore.alias |
The alias of the server's own key as found in the keystore.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.keystore.type |
The file format of the keystore.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.truststore.file |
If the client authentication mode is "true" or "want", this truststore is used to verify client certificates.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.truststore.password |
The password of the truststore file so it can be accessed in order to verify client certificates.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.truststore.type |
The file format of the truststore.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.secure-socket-protocol |
The secure protocol that browser clients should use to communicate with the RHQ Console.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.client-auth-mode |
Indicates if the remote client should be authenticated or not. Values are "true" (all clients must authenticate with a certificate), "want" (clients that have a certificate must be authenticated; anonymous clients do not need to authenticate) or "false" (no client needs to authenticate with a certificate).
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.tomcat.security.algorithm |
The algorithm used to store data in the keystore and truststore.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
These settings define how the RHQ Server will accept incoming messages from the RHQ Agents. See Communications Configuration for more information on setting up the RHQ Server's agent communications subsystem.
rhq.communications.connector.transport |
Defines how the RHQ Agents need to transport messages to the RHQ Server. Typical values are "servlet", "socket", "sslservlet" and "sslsocket".
If you elect to use "servlet" or "sslservlet", it means you plan on routing agent requests through the RHQ Server web application layer (i.e. the secure Tomcat Connector).
If you elect to use "sslservlet", not only will agent requests route through the web application layer, but it also is secured though the secure Tomcat Connector as well. What this means is that the keystore used for incoming agent message authentication will be the same as that which you set up as described in RHQ Console Transport Security.
It is recommended that if you want to fully authenticate incoming agent requests, that you use "sslsocket" transport to allow for more flexibility in the configuration of the incoming security layer.
(
Prior to 2.1)
rhq.communications.connector.bind-address |
The address that the RHQ Server will bind its connector to so it can receive RHQ Agent messages.
(
Prior to 2.1)
rhq.communications.connector.bind-port |
The port that the RHQ Server will listen to in order to accept RHQ Agent messages.
rhq.communications.connector.transport-params |
Defines additional transport parameters the RHQ Server will set on its connector that will accept incoming messages from the RHQ Agents. See Communications Configuration#TransportParameters for full details on transport parameters.
rhq.communications.multicast-detector.enabled |
If true, the RHQ Server will allow RHQ Agents to attempt to auto-detect the RHQ Server coming online and going offline using multicast detection. Your network must support multicast traffic for this to work.
rhq.communications.multicast-detector.bind-address |
The address that the multicast detector will directly bind to. This is not needed nor used if you have not enabled multicast detection.
rhq.communications.multicast-detector.multicast-address |
The address that the multicast detector will broadcast messages to. This is not needed nor used if you have not enabled multicast detection.
rhq.communications.multicast-detector.port |
The port that the multicast detector will broadcast messages to. This is not needed nor used if you have not enabled multicast detection.
These settings define how the server will secure its communications channel when accepting incoming messages from the RHQ Agents. See Securing Communications for more detailed information on setting up the Server-Agent communications security.
Note that if you are not using a secure incoming transport, these settings are not used.
The other half of the communications channel (that is, the outgoing side) has analogous settings. You can share keystores, truststores and other settings for both sides, or you can customize your communications for either side independently.
rhq.communications.connector.security.secure-socket-protocol |
The secure protocol that agents must use when communicating with this RHQ Server.
rhq.communications.connector.security.keystore.file |
The keystore file that contains a certificate that authenticates the RHQ Server to the agents.
rhq.communications.connector.security.keystore.algorithm |
rhq.communications.connector.security.keystore.type |
The file format of the keystore.
rhq.communications.connector.security.keystore.password |
The password that is used to gain access to the keystore file.
rhq.communications.connector.security.keystore.key-password |
The password that is used to gain access to the key inside the keystore.
rhq.communications.connector.security.keystore.alias |
The alias that identifies the RHQ Server's key within its keystore.
rhq.communications.connector.security.truststore.file |
The truststore file that contains certificates that this RHQ Server trusts. If you want or need the RHQ Server to authenticate RHQ Agents, you must set this; otherwise it is not needed. This truststore will contain certificates for all RHQ Agents that need to communicate with this RHQ Server.
rhq.communications.connector.security.truststore.algorithm |
rhq.communications.connector.security.truststore.type |
The file format of the truststore file.
rhq.communications.connector.security.truststore.password |
The password that is used to gain access to the truststore file.
rhq.communications.connector.security.client-auth-mode |
Indicates if you want or need the RHQ Server to authenticate the RHQ Agents that are sending it messages. If you are using a secured transport but do not have trusted certificates for all of your RHQ Agents in a truststore, you must set this to none.
Valid values are: none, want or need
These settings define how the server will secure its communications channel when sending outgoing messages to the RHQ Agents. See Securing Communications for more detailed information on setting up the Server-Agent communications security.
The other half of the communications channel (that is, the incoming side) has analogous settings. You can share keystores, truststores and other settings for both sides, or you can customize your communications for either side independently.
Note that if your RHQ Agents are not using a secure transport, these settings are not used.
rhq.server.client.security.secure-socket-protocol |
The secure protocol that the server must use when sending outgoing messages to agents. The agents must be expecting to use this protocol for messages that it receives.
rhq.server.client.security.keystore.file |
rhq.server.client.security.keystore.algorithm |
rhq.server.client.security.keystore.type |
rhq.server.client.security.keystore.password |
rhq.server.client.security.keystore.key-password |
rhq.server.client.security.keystore.alias |
rhq.server.client.security.truststore.file |
rhq.server.client.security.truststore.algorithm |
rhq.server.client.security.truststore.type |
rhq.server.client.security.truststore.password |
rhq.server.client.security.server-auth-mode-enabled |
Indicates if you want the RHQ Server to authenticate the RHQ Agents that it is sending messages to. If you are using a secured transport but do not have trusted certificates for all of your RHQ Agents in a truststore, you must set this to none.
You have the option of installing the RHQ Agent embedded directly in the RHQ Server, as opposed to installing and running a separate process for the RHQ Agent. The embedded agent operates just like its standalone counterpart, the only difference is it is running in the same Java virtual machine as the RHQ Server. Note that if you do this, you will not have the option of a command line interface to the agent, as you would have with a standalone RHQ Agent.
rhq.server.embedded-agent.enabled |
Set this to true if you want to run the embedded RHQ Agent inside this RHQ Server. Set this to false if you want to run the RHQ Agent as a separate process or if you do not want a RHQ Agent running on the same machine as your RHQ Server.
Use the embedded agent for demo/testing purposes only. It is not recommended to use it in a production environment.
rhq.server.embedded-agent.name |
The name that the embedded RHQ Agent will register itself as.
rhq.server.embedded-agent.disable-native-system |
The RHQ Agent has JNI native components that is used to perform some tasks. If you are having problems with the native components, you can completely disable their usage by setting this to true. Typically, you can leave this as false under normal conditions.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
rhq.server.embedded-agent.reset-configuration |
If this is set to true, the embedded agent will reset its configuration at startup. Resetting the configuration means it will clear out any configuration settings currently persisted in the preferences store and reload the configuration from its built-in configuration file (i.e. the defaults it shipped with out-of-box). If false, the embedded agent will retain the configuration it had when it last was running - which may be different from its original configuration if a user changed those configuration settings from the RHQ Console. Note that this setting will not effect those configuration settings that are explicitly defined in or are derived from the rhq-server.properties startup properties file. This includes things like IncomingAgentCommunicationsTransport (which tells the embedded agent how to talk to the server).
rhq.server.email.smtp-host |
The hostname of the SMTP server that is used when the RHQ Server sends emails.
rhq.server.email.smtp-port |
The port that the RHQ Server will send emails over when communicating with the SMTP server.
rhq.server.email.from-address |
The "From:" header of all emails sent by the RHQ Server.
rhq.server.operation-timeout |
One of the features of RHQ is the ability to invoke operations (aka control actions) on a resource. The RHQ Server will be able to ask an agent to invoke a particular operation on a particular resource managed by that agent. Because of the remote, asynchronous nature of operation invocations, alot of things can go wrong (the network goes down, the resource crashes, etc.). This operation timeout is the default number of seconds that the RHQ Server will wait for an operation to complete and an agent to provide the results. If this timeout expires, the operation will be considered to have failed. Note that this is only a fallback default value - individual operations can define their own timeouts (in the plugin descriptor) or individual operation invocations can themselves specify a timeout. Those override this default rhq.operation-timeout setting.
RHQ is designed to scale to large numbers of agents. The RHQ Server must, therefore, take into account the possibility that it could get flooded with messages if many or all agents attempt to communicate with the server simultaneously (as will be the case if the RHQ Server is restarted after being down for a while; RHQ Agents will detect the RHQ Server has come back up and will attempt to immediately send it a backlog of messages).
To help alleviate problems that could occur during high load, the RHQ Server is configured to limit the number of concurrent messages allowed to be processed by different subsystems within the RHQ Server. If more messages arrive concurrently, such that the limit is exceeded, those additional messages will be dropped and the agent will be asked to send them later. The following configuration settings define types of messages that have concurrency limits associated with them.
rhq.server.startup.web.max-connections |
RHQ limits the number of web connections that can be concurrently created. This includes GUI connections made by browsers. It may also include connections made by agents, if agent connections are made via the servlet transport (see Incoming Agent Communications Transport). Note that if agent requests are routed over web connections, you should ensure that the Global Concurrency Limit is slightly lower than this Web Connections limit so as not to lock out GUI users from accessing the user interface during times of high agent load.
This limit on web connections is the same for both non-secured http requests and secured https requests, so the total max connections allowed is actually twice what this setting is. For example, if the max web connections is set to 300, then 300 http requests will be allowed and 300 https requests will be allowed, for a possible total of 600 concurrent web connections.
rhq.communications.global-concurrency-limit |
Aside from the Web Connections limit, all other concurrency limits will only affect incoming agent messages (not GUI/browser requests). This global concurrency limit will limit the total number of agent messages coming into the server, regardless of the type of message. In other words, if this global concurrency limit is set to 300, no more than 300 total agent messages can be processed at any one time, no matter what kinds of messages are coming in. The rest of the concurrency limit settings will put a limit on the number of messages of particular message types. Keep in mind that if other concurrency limits are set higher than this global limit, they are effectively capped at this global limit since you can never have more than this global limit number of messages concurrently being processed.
rhq.server.concurrency-limit.inventory-report |
Inventory reports are sent from the agent when the agent starts up and periodically thereafter. Inventory reports can be large, depending on the number of resources on the agent machine.
rhq.server.concurrency-limit.availability-report |
Availability reports are sent from the agent very often (typically every 5 minutes). Availability reports are usually very small, but occur in large numbers due to the high frequency of their transmission.
rhq.server.concurrency-limit.inventory-sync |
Inventory synchronizations occur when the agent needs to synchronize its inventory with that of the server. Agents typically synchronize at startup. Traffic that flows as part of inventory synchronizations is usually large, depending upon the number of resources managed by the agent.
rhq.server.concurrency-limit.content-report |
Content reports are similar to inventory reports except they contain information about discovered content (i.e. installed packages of software). These reports can be large depending on the number of installed software the agent has discovered and is managing.
rhq.server.concurrency-limit.content-download |
Content downloads occur when a resource on an agent needs to ask for the content of a package version, usually for the purpose of installing the package.
rhq.server.concurrency-limit.measurement-report |
Measurement reports are sent to the server periodically whenever the agent completes measurement collections. The number of measurement reports vary as do their size, depending on the number and frequency of measurements that are scheduled to be collected. The greater the number of schedule measurements the agent needs to collect, the more frequently measurement reports are sent and the larger they are.
rhq.server.concurrency-limit.measurement-schedule-request |
Similar to inventory synchronization, measurement schedule requests are sent to the agent when the agent wants to ask the server for its up-to-date set of measurement schedules that have to be collected.
rhq.server.plugin-scan-period-ms |
Periodically, the RHQ Server will scan it is local file system and the database to see if any changes have been made to deployed agent plugins and server plugins. This value is the amount of milliseconds the server waits before checking its plugins again.
rhq.sync.endpoint-address |
When this is enabled (i.e. set to true), the server will, at start up, compare its endpoint address to the host name/address found on the host machine. If they differ, the server endpoint address will be updated to the value found on the host machine. This addresses the problem of address/host name changes that will occur in cloud deployments such as EC2 when a server machine is restarted.
There are several rhq.autoinstall settings to allow you to install the RHQ Server without administrator intervention (i.e. without the need to go through the installer webapp). Read the Auto Installer documentation for more information.